[レポート] New Relic University 2019.10.9 に参加してきました

こんにちは ttaka です。

2019年10月09日に開催された「New Relic University - New Relic でパフォーマンス分析を10倍早くしてみよう！速習ハンズオン講座」への参加レポートとなります。当日いただいた資料とメモをもとに書いた内容となりますので、誤った理解や記載がある場合はご容赦ください（およびご連絡ください）。

講座に参加しようとしたきっかけ

私が過去に扱ってきたシステムの多くはモノリシックなアプリケーションをロードバランサ、Web サーバ、DB サーバの構成で動かすものがほとんどでした。また監視もメトリックを取得していましたがメトリック監視は行わず、チェック監視（OK/NG）を使用してシステムの状態を監視することが多くありました。

そういったシステムが今後もなくなることは無いし、今まで培ってきた知識や経験も活かしていけると思う一方で、サーバレスやコンテナのシステムが増えてきているため、そういった近年のシステムをどう監視していくのか？を学ぶために New Relic University に参加してきました。

講座のゴール

・近年のアプリケーションに必要と言われている可観測性についての理科を深める
・New Relic を使って簡単に可観測性を実現する方法を知る
・アプリケーションのエラーやパフォーマンス問題に対し、迅速に対処する方法を知る
・クラウドの稼働状況（マネージドサービスを含むパフォーマンス、コスト等）を正しく把握する方法を知る
・上記のような情報をダッシュボードで可視化したり、アラートとして定義する方法を知る

（引用： 当日配布された資料 ）

アジェンダ

• 座学1: 可観測性と New Relic/New Relic APM
• ハンズオン1: アプリケーションパフォーマンスの測定
• 座学2: New Relic Infrastructure
• ハンズオン2: クラウドのパフォーマンスとコストの把握
• 座学3: ダッシュボード・アラート
• ハンズオン3: ダッシュボード

可観測性と New Relic/New Relic APM

• 可観測性とは「システムの状態を監視する行為」ではなく監視に必要な情報をシステムが取得可能な状態
• 可観測性が重視されてきている理由
  • これまでのシステムが１つのモノリシックなアプリケーションであったのに対して、近年のシステムはコンテナなどを利用したマイクロサービスとなっている
  • そのため、リソースや死活といった状態を見るだけではなく、関連するコンポーネント群の関係性を把握する必要がある
• 可観測性には 3 つの要素がある
  • メトリック：集計可能なデータの粒
    • キュー深度
    • HTTP リクエスト数
  • トレース：単一トランザクションを構成するあらゆる要素
    • 外部 API へのリクエスト
    • DB へのクエリ
  • ログ：個々のイベントの記録
    • デバッグログ
    • エラーログ

　参考: Metrics, tracing, and logging

• New Relic の目指すもの
  • あらゆるテレメトリデータを一箇所に集約
    • New Relic Agent
      • 様々なコンポーネントから JSON 形式の Event データを収集
    • New Relic Metrics
      • オープンソースなどからメトリックデータを収集
      • 統一されたフォーマットに変換
    • New Relic Traces
      • エージェントを持たないサービスであっても分散システムを把握できるビューを提供
    • New Relic Logs
      • New Relic APM/Infrastructure と連携
      • ログデータをアプリケーションやシステムのパフォーマンスと結びつけて表示
  • 集約したデータを自在に分析し、ダッシュボードやアラートとして活用
    • New Relic One
      • 画面の構成をプログラミングで柔軟にカスタマイズできる機能
• New Relic APM
  • 言語ごとにアプリケーションで稼働するエージェント
  • 導入すれば数分でアプリケーションの状態を可視化できる
  • コンテナやサーバレスを含むあらゆる環境に導入可能
    • サーバ・仮想マシン：OS でコマンドを実行しエージェントを土入
    • コンテナ：エージェントを導入したコンテナイメージを作成
    • サーバレス（Lambda）：Lambda 関数のパッケージにエージェントを導入
• アプリケーションの可視化がもたらす効果
  • トラブルシューティングの迅速化
    • エラーの増加を発見
    • エラーの原因を New Relic 上で追求
  • パフォーマンスの最適化
    • パフォーマンスの劣化を発見
    • ボトルネックとなっている場所をコードレベルで解析
  • イノベーションの促進
    • リリース前後のパフォーマンスを比較
    • マイクロサービス化されていても依存関係を把握しながら分析可能

New Relic Infrastructure

• インフラリソース用のエージェント
• 導入方法
  • OS, Kubernetes：エージェントのインストール
  • クラウドのマネージドサービス：インテグレーションを構築しクラウドから各種メトリクスを取得
• ミドルウェアとの連携
  • 追加モジュールを提供
  • インストールすることでミドルウェアのメトリックを取得可能
• アプリケーションとインフラの相関関係の把握
  • アプリケーションとそれを稼働させているインフラの状態を一覧表示
  • K8s の Pod を選択するとその Pod 内で動いているアプリケーションの状態を表示

New Relic One - ダッシュボード・アラート

• 2019年5月にリリースされた新しい UI
• 新しいダッシュボード機能やスマートアラート機能（今後リリース予定）を搭載
• ダッシュボードを活用する場面
  • データの選択と集約
    • 複数アプリケーションやアプリケーションとインフラのメトリックの相関関係などを１つの画面に表示
  • データの加工
    • チームで定めた KPI に対する実測値を把握
  • データのビジュアライズ
    • 集めたデータを目で見てわかりやすい形式で表示

感想

例えば過去私が対応した障害時などは、実際にサーバにログインして情報を集めたり、リソースグラフなどで情報を集めるなどして対応を行っていました。また、その際にはアプリケーションの可視化などはされていなかったので、アプリケーションのログを追いかけるようなこともしていました。そのため、New Relic の目指すものがシンプルながらとても魅力的に感じました。

また、参加前は UI が複雑な印象を持っていたのですが、今回の講座で可観測性の 3 つの要素があり、それに対してどのような手段を用意されているかを学び、実際にハンズオンで手を動かすことで、New Relic への理解を深めることができました。

ただ懇親会で中の人とお話する機会があったのですが、New Relic でも Mackerel でも Datadog でも導入するのがゴールではなくスタートになるので、引き続き監視（可観測性）への理解を深めて発信できればなと思います。